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METHOD AND APPARATUS FOR AUTOMATING SOFTWARE UPGRADES 
CROSS-REFERENCE TO RELATED APPLICATIONS 



[0001] This application is a related to U.S. patent application serial no. 09/865,371 , 
filed on May 25, 2001 , entitled METHOD AND APPARATUS FOR UPGRADE 
ASSISTANCE USING CRITICAL HISTORICAL PRODUCT INFORMATION; U.S. patent 
application serial no. 09/892,424, filed on June 27, 2001 , entitled APPARATUS, 
METHOD, AND BUSINESS METHOD FOR ENABLING CUSTOMER ACCESS TO 
COMPUTER SYSTEM PERFORMANCE DATA IN EXCHANGE FOR SHARING THE 
PERFORMANCE DATA; and U.S. patent application serial no. 09/892,435, filed on 
JUNE 27, 2001 , entitled APPARATUS, METHOD, AND BUSINESS METHOD FOR 
ENABLING CUSTOMER ACCESS TO COMPUTER SYSTEM EXECUTION DATA IN 
EXCHANGE FOR SHARING THE EXECUTION DATA. 



BACKGROUND OF THE INVENTION 
Field of the Invention 

[0002] The present invention generally relates to software upgrades. More 
particularly, the present invention relates to automation of software upgrades utilizing 
computer implemented methods for verifying currently installed software on a system 
and ordering a customized software upgrade. 

Description of the Related Art 

[0003] Generally, software upgrades are periodically released to improve previous 
versions/releases of the same software, and correspondingly, customers periodically 
update their software versions/releases to the software upgrades. Traditionally, 
upgrading to the current software version/release is a time-consuming manual process 
that involves both the customer and the software sales representative in various tasks. 
In a typical software upgrade process, after being notified of a software upgrade 
release, the customer contacts the software sales representative to request the software 
upgrade. The sales representative must verify that the customer is entitled to the new 
version/release (e.g. they have the right business contracts and they have Proof of 

2 



Entitlement (POE) for the software). Then, the software sales representative must 
determine the software inventory currently installed on the customer system and 
whether that software has changed configuration in the new version/release. The 
software sale representative also needs to validate the customer software inventory 
against administrative database records, updating administrative records as required to 
synchronize records. The sale representative then prepares and submits a software 
configuration order to the customer for order approval. The software configuration order 
is then forwarded through the administration system to a fulfillment and distribution 
center, where the software order is prepared and shipped to the customer. The process 
for a customer to obtain a software upgrade usually takes many days (sometimes more 
than a week) because of the required manual tasks performed by both the customer 
and the sales representative. 

[0004] In addition to the time consumed by this laborious process, the traditional 
software upgrade process is also error-prone due to the many manual steps and the 
complexities involved with software configuration (e.g., pre-requisites and co-requisites). 
Because the demands of world wide e-business solutions which require constant 
availability, customers cannot afford to be "out of service" for any period of time. 

[0005] Therefore, a need exists for a more expedient way for customers to obtain 
software upgrades, particularly, minimizing the required manual tasks performed by the 
customer and the sales representative while maximizing accuracy of the software 
upgrade order. 



SUMMARY OF THE INVENTION 

[0006] Embodiments of the invention generally provide method and apparatus for 
obtaining software upgrades. One embodiment provides a method for upgrading one or 
more software releases on a customer computer, comprising: receiving, by a supplier 
system, a software inventory from the customer system; verifying one or more business 
contracts for the software inventory utilizing one or more databases connected to the 
supplier system; and determining one or more software upgrade releases for the 
software inventory utilizing a product topology database connected to the supplier 
system. 
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[0007] Another embodiment of the invention provides a method for collecting 
information on the installed software on the customer's machine and processing the 
collected information in a supplier system. The customer's currently installed software 
inventory may be utilized to simplify the upgrade process and to improve accuracy of the 
software upgrade. 

[0008] Another embodiment provides automation of software configuration based on 
a data modeling of the software product topology, mapping of release to release 
changes and verifying pre-requisite/co-requisite information. 

[0009] Still another embodiment provides for integration with business processes to 
fully automate the software upgrade transaction. This includes the software Inventory 
collection and automation of software configuration, as well as automatic entitlement 
checking and programmatic interfaces to fulfillment and distribution systems. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] So that the manner in which the above recited features, advantages and 
objects of the present invention are attained and can be understood In detail, a more 
particular description of the invention, briefly summarized above, may be had by 
reference to the embodiments thereof which are illustrated in the appended drawings. 

[001 1] It is to be noted, however, that the appended drawings illustrate only typical 
embodiments of this invention and are therefore not to be considered limiting of its 
scope, for the invention may admit to other equally effective embodiments. 

[0012] FIG. 1 is a high-level diagram of a networked environment. 

[0013] FIG. 2 is a system diagram of an environment having a owner/customer side 
and a supplier side. 

[0014] FIG. 3 is an overall dataflow for combining workload requirements in 
generating an order. 

[0015] FIG. 4 is a performance collection data structure. 
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[0016] FIG. 5 is an illustrative agent function flow. 

[0017] FIG. 6 is an illustrative method for compiling and summarizing historical data. 

[0018] FIG. 7 is an illustrative solution input flow defining how third party solutions or 
capacity planners can input their workflow impact into a defined process. 

[0019] FIG. 8 is an illustrative system sizer process. 

[0020] FIG. 9 is an illustrative comparison process for comparing different product 
capabilities and prices. 

[0021] FIG. 10 is an illustrative configuration process for determining a valid system. 

[0022] FIG. 11 is an illustrative order process to build and communicate successful 
order acceptance. 

[0023] FIG. 12 is a graphical user interface of a homepage for a customer system 
supplier. 

[0024] FIG. 13 is a graphical user interface formatted to show trends based on 
historical data. 

[0025] FIG. 14 is a graphical user interface detailing trend and history information in 
a graphical format. 

[0026] FIG. 1 5 is a graphical user interface illustrating a workload selection page. 

[0027] FIG. 16 is a graphical user interface illustrating a workload definition page. 

[0028] FIG. 17 is a graphical user interface illustrating an advanced growth options 
page. 

[0029] FIG. 18 is a graphical user interface illustrating a recommendation page. 

[0030] FIG. 1 9 is a graphical user interface illustrating a comparison page. 

[0031] FIG. 20 is a graphical user interface illustrating a comparison page. 

[0032] FIG. 21 is a graphical user interface illustrating a configuration page. 
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[0033] FIG. 22 is a graphical user interface illustrating an order entry screen. 

[0034] FIG. 23 is a diagram of a network environment comprising a plurality of client 
computers networked with a sizing system and a configuration information supplier 
system. 

[0035] FIG. 24 is an architecture diagram of one embodiment of a physical device 
placement system. 

[0036] FIG. 25 is an architecture diagram of another embodiment of a physical 
device placement system. 

[0037] FIG. 26A is an exemplary Interface file input to a configuration server. 

[0038] FIG. 26B is an exemplary interface file output from a configuration server. 

[0039] FIG. 27 is an illustrative graphical user interface configured for input of a 
machine type, plant code and serial number. 

[0040] FIG. 28 is an illustrative graphical user interface configured for input of a base 
system. 

[0041] FIG. 29 is an illustrative graphical user interface configured for input of a 
purchase order number. 

[0042] FIG. 30 is a flowchart illustrating a method for handling device placement 
requests. 

[0043] FIG. 31 is a flowchart illustrating a method for handling device placement 
requests introduced in FIG. 7. 

[0044] FIG. 32 is a flowchart illustrating a method for handling a machine specific 
device placement request using customer supplied data. 

[0045] FIG. 33 is a flowchart illustrating a method for handling a base system request 
type. 

[0046] FIG. 34 is a flowchart illustrating a method for handling a purchase order 
request type. 
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[0047] FIG. 35 is an illustrative graphical user interface configured for displaying 
results of a placement query. 

[0048] FIG. 36 shows one embodiment of a processing system 3600 for providing 
software upgrades to customers. 

[0049] FIG. 37 is a flow diagram illustrating one embodiment of a method 3700 for 
processing a software upgrade request. 

[0050] Figure 38 illustrates one embodiment of a GUI 3800 configured for a login 
request. 

[0051] Figure 39 illustrates one embodiment of a GUI 3900 configured for displaying 
messages to a user. 

[0052] Figure 40 illustrates one embodiment of a GUI 4000 configured for user 
selection of a specific customer system to be upgraded. 

[0053] Figure 41 Illustrates one embodiment of a GUI 41 00 configured for user 
selection of a target release for the software upgrade. 

[0054] Figure 42 illustrates one embodiment of a GUI 4200 configured for user 
selection of languages for the software upgrade. 

[0055] Figure 43 illustrates one embodiment of a GUI 4300 configured for user 
acceptance of a software upgrade order. 

[0056] Figure 44 illustrates one embodiment of a GUI 4400 configured for user 
confirmation of entitlement to a software upgrade. 

[0057] Figure 45 illustrates one embodiment of a GUI 4500 configured for user 
verification of shipping address for a software upgrade order. 

[0058] Figure 46 illustrates one embodiment of a GUI 4600 configured for providing 
a receipt with confirmation/tracking number for a software upgrade order. 

[0059] Figure 47 is a flow diagram illustrating one embodiment of a method 4700 for 
processing a software upgrade request. 
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[0060] Figure 48 illustrates one embodiment of a vital product data (VPD) table 
4800. 

[0061] Figure 49 illustrates one embodiment of a Cross Release ID (GRID) iVIap 
4900. 

[0062] Figure 50 is a flow diagram illustrating one embodiment of a method 5000 for 
determining software to be ordered. 

[0063] Figure 51 shows one embodiment of product categories utilized for step 5020. 

[0064] Figure 52 illustrates embodiments of the Release to Release Mapping step 
5030. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

System Sizing and Configuration 

[0065] Embodiments of the present invention provide for an integrated methodology 
simplifying the upgrade choices for complex computer products through the use of 
automation and integration of product monitoring and business applications. In general, 
a method comprises data collection and summarization, transmission, workload 
estimation, solution generation, configuration and product ordering. In one 
embodiment, methods and systems provided herein are configured with Web-based 
capabilities. However, any networked environment and interface format may be used to 
advantage. 

[0066] FIG. 1 is a diagram of a networked environment 1 00 generally defining a 
relationship between a computer system customers/owners side 1 02 and a computer 
system supplier side 1 04 (the "supplier 104"). The customers/owners side 102 may 
include any person, group of persons or enterprise who individually or collectively 
operate one or more computer systems 1 06i , 1 062. . . 1 06n. The computer systems may 
be any computerized device including personal computers (PCs), workstations, servers, 
wireless devices, personal digital assistants (PDAs), and the like. Each computer 
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system 106 includes a performance database 11 d, IIO2...IION containing performance 
data about various system resources, threads of execution, configuration information, 
etc., for the computer system 106. Each computer system 106 further comprises an 
data collector agent IO81, IO82...IO8N (referred to as the "agent 108"). The agent 108 
may be any combination of software and hardware configured to automate collection 
and summarization of the performance data. One commercially available agent is the 
PM/400 agent available from International Business Machines, Inc. The resulting agent 
data is stored in an agent database 1 12i, 1 122...I 12n and is periodically exported to the 
supplier 104. Subsequently, the computer system 106 may execute a client program 
107 (e.g., a web browser) to access the data managed by the supplier 104. 

[0067] The supplier 1 04 is any entity or organization capable receiving, processing 
and maintaining agent data from a plurality of customer computer systems 106 in order 
to facilitate product and system upgrades/enhancements. The supplier 104 operates a 
supplier system 105 configured to establish a network connection with one or more of 
the customer computer systems 106 via a network 103. In one embodiment, the 
network 103 is the Internet. In another embodiment is a network private 
connection/network between the customer system 102 and the supplier system 105. 
Illustratively, the supplier system 105 comprises a historical summary server 1 14 and a 
system sizer 1 1 6. The historical summary server 1 1 4 and/or the system sizer 1 1 6 are 
each in communication with a plurality of databases 117. The databases 117 include a 
history tables database 11 8, a solutions table database 1 1 9C, a recommendation tables 
database 120, a starting configuration tables database 121 , a configured system 
database 122 and an order tables database 123. In one embodiment, the system sizer 
116 is configured with or configurable with one or more solution plug-ins 124, which 
include capacity planners 125 (shown in FIG. 2). 

[0068] As shown in FIG. 1 , the supplier system 1 05 includes a plurality of solution 

tables databases 1 1 9A-C. The solution tables databases 1 1 9A-C (collectively referred 

to as solution tables database 1 1 9) indicate that solution tables may be 

generated/provided by various means and sources. A first solution tables database 

1 19B is shown associated with the historical summary server and represents solution 

tables generated using the information contained in the history tables database 1 1 8. A 

second solution tables database 1 1 9B is shown associated with the solution plug-ins 

124 and represents solution tables for third-party system solutions. A third solution 
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tables database 1 1 9C represents any other sources of solution tables including, for 
example, solution tables generated in response to user supplied information while 
interacting with the supplier system 105 (e.g., while interacting with a web page hosted 
by the supplier system 105). The user-supplied information may be provided in 
response to predefined questions presented by the supplier system 1 05 to a user or by 
modifications made by the user to information provided by the supplier system 105. 

[0069] The operation of the networked environment 1 00 may be described with 
reference to FIG. 2. The overall operation is indicated by a series of circled numerals, 
wherein each numeral represents one or more processing steps. Any and all stages of 
the illustrated business process may be performed iteratively, thus enabling a user (e.g., 
the customers 102, the supplier 104, and business partners) to address a total solution. 

[0070] For purposes of illustration, only one customer/owner computer system 1 06 is 
shown in FIG. 2. However, it is understood that the supplier system 105 will typically 
communicate with a plurality of computer systems 106 (as shown in FIG. 1). It should 
also be understood that the computer 106 making a request for upgrade information 
may or may not be the same computer that initially provided the relevant agent data. It 
is further understood that while Fig. 2 shows only one solution table 1 1 9, a plurality of 
solution tables may be provided. 

[0071] Initially, raw performance data from the computer system 106 is collected and 
stored in the performance data database 110. Performance data collection may be 
facilitated by a product and/or system specific function such as the 0/S 400 Collection 
Services available from International Business Machines Inc. Embodiments for data 
collection which may be used to advantage are further described in U.S. patent 
application serial no. U.S. patent application serial no. 09/892,424, filed on June 27, 
2001, entitled APPARATUS, METHOD, AND BUSINESS METHOD FOR ENABLING 
CUSTOMER ACCESS TO COMPUTER SYSTEM PERFORMANCE DATA IN 
EXCHANGE FOR SHARING THE PERFORMANCE DATA; and in U.S. patent 
application serial no. 09/892,435, filed on JUNE 27, 2001 , entitled APPARATUS, 
METHOD, AND BUSINESS METHOD FOR ENABLING CUSTOMER ACCESS TO 
COMPUTER SYSTEM EXECUTION DATA IN EXCHANGE FOR SHARING THE 
EXECUTION DATA, which are incorporated by reference in their entirety. 
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[0072] The performance data is then summarized and exported to the supplier 
system 105. The summarized and exported data is referred to as agent data and is 
contained in the agent data database 112. 

[0073] Summarization and exportation need not occur on the same cycle. For 
example, performance data may be collected daily while agent data may be exported 
daily, weekly or monthly. In one embodiment, the agent process on a customer system 
106 is activated to automate the process of summarizing raw performance data for 24 
hour time period. The summarized agent data is processed to determine averages, 
peaks, minimums, and maximums by job, job type, workloads, user, and total system for 
that time period (i.e., the 24 hour time period). The granularity of data is determined 
according to the age of the data, with granularity decreasing with age. This occurs 
because over time the data is processed and condensed. 

[0074] Upon receipt by the supplier system 1 05, the agent data is stored to a 
historical tables database 118, which is under the control of the historical summary 
server 114. In one embodiment, the historical summary server 114 maintains twenty- 
four months worth of historical data for the plurality of computer systems 1 06 in the 
historical tables database 116. At some timed interval (e.g., monthly) the historical 
summary server 1 1 4 operates to merge the summarized agent data with older history 
data (previously collected from the same computer system 106) in the historical tables 
database 118. Data in the centralized data repository (History data) is processed by 
some timed interval (monthly) creating a daily, weekly, and/or monthly profile to show 
statistically and graphically what happens week to week and month to month etc. In 
particular, the historical data is analyzed to determine growth rates, consumption rates, 
monthly averages, seasonal peaks, growth parameters, and trends using the data 
provide by the customer systems 1 06. In this manner, the supplier 105 is provided with 
important summarized statistics for later use. 

[0075] Summarized performance data contained in the historical tables database 
1 1 8 is then fed into a system sizer 1 1 6. The role of the system sizer 1 1 6 is to analyze 
the data and determine system resource requirements currently needed (current system 
needs) and those resources that might be needed at a future time (projected system 
needs). One system sizer that may be used to advantage is the IBM Workload 
Estimator for iSeries available from International Business Machines, Inc. Illustrative 
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system resources that may be accounted for by the system sizer 116 include the system 
CPU, the system memory, the hard disk, etc. 

[0076] In one embodiment, the system sizer 1 1 6 defaults the performance 
requirements to current system usage. The end user of the system/component has 
numerous options to then tailor and customize the projection. The user selects from the 
amount of CPU, interactive capacity, DASD, memory, etc., to control the growth 
projections that best reflect the system's use. The user can also select periods most 
representative of the system's typical work load by removing those that do not apply. 
The user can then modify the intended use of the system based on new 
programs/applications and solutions such as Domino serving, server consolidation, or 
Websphere serving, for example. The user may iterate through this step of the process, 
trying out variations ("What-ifs") for workloads to include, workload definition details, 
assumptions, and growth options before proceeding to the next step. 

[0077] In one embodiment, the system sizer 1 1 6 provides for tying in the capabilities 
of capacity planners 125 and solution plug-ins 124. Such an arrangement may be 
particularly beneficial where the system sizer 1 16 is Intended to be a quick and easy-to- 
use component with accuracy sufficient for marketing purposes. Where much greater 
accuracy and precision Is desired, the system sizer 116 could communicate with a 
capacity planner 125 (by the supplier 1 05 or a 3rd party). As Is well-known, capacity 
planners employ elaborate and detailed system models to project with great accuracy 
and precision. An exemplary capacity planner which may be used to advantage is 
Best/1 available from BMC Software, Inc. 

[0078] Additionally or alternatively, solution providers can define plug-ins 124 to the 
system sizer 116. This provides a means to externally describe the Impacts of the 
solution on the system resources and have them considered as part of the overall affect 
of the total needs of a user. For example, system sizer 116 may utilize impact 
descriptions provided by third-party solutions such Domino and Websphere. To this 
end, the system sizer 116 supports the plug-in screen displays, parameter inputs, and 
solution-specific system resource requirements inclusion into the total system resource 
requirements. 
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[0079] The final output of the system sizer 1 1 6 is a recommendation table which is 
stored to the recommendation table database 120. The recommendation table provides 
a single resource impact view across one or more solutions by compiling the input from 
various solution suppliers and the base computer system 106. 

[0080] The system sizer 1 1 6 employs a system model selection function, referred to 
as the comparison tool 202, to construct the set of all systems capable of meeting the 
system capacity requirements. In one embodiment, the comparison tool 202 is the 
AS/400 FACT, available from International Business Machines, Inc. The solution set 
can be limited depending on specific user needs. Available user-selectable controls 
include (but are not limited to) orderable upgrade to existing system or new system, 
specific system model types (e.g., low ends, servers dedicated to specific workloads, 
latest models being sold), excess capacity for future needs, etc. To construct a solution 
set, the comparison tool 202 uses the recommendation table generated by the system 
sizer 116 as input, provides the user with additional modification options (according to 
an available product line) and produces a starting systems configuration table. This 
resulting table is stored to the starting configuration tables database 121 . 

[0081] Invoking a configuration tool 204, the supplier system 1 05 then automatically 
configures specific system feature codes based on recommended system solutions. 
The configuration can be further tailored and expanded to include hardware/software 
components not identified in the system sizing (e.g., tape drives, network adapters, 
licensed software products, etc.). Taking the starting system configuration table 
(generated by the comparison tool 202) as input the configure process allow for the 
addition of other resources and produces a final orderable system configuration based 
on the total solution view determined earlier. 

[0082] The complete system configuration (new or upgrade) feature code list is then 
passed to a system order placement function 206 (also referred to herein as the "order 
function 206"). The order function 206 is configured to format an order table which is 
then stored to the order table database 123. A supplier representative, business 
partner representative, or end user can inquire about schedules and status of orders 
placed by inspecting (e.g., via a Web interface or some other user interface) the order 
table. 
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[0083] The foregoing process provides value at any given stage and the value of the 
process compounds as more stages are included. Accordingly, the process does not 
require completion in a continuous effort. To the contrary, the process is flexible and 
allows for exiting at the different stages and later re-entry to continue the process. To 
achieve this result, a user's state of progression is preserved and passed between each 
of the different layers. For example, the data that enables the comparison tool 202 is 
the same data needed for the configurator definition processes. 

[0084] In addition, the foregoing process is sensitive to the different levels of 
expertise of users utilizing the supplier system 105. To improve the productivity of all 
groups, the embodiments of the present invention provide each individual the ability to 
enter the process at their own comfort level. By driving as much of the process through 
realtime data directly from the supplier system 105, and solution tables from solution 
supliers 124 the overall expertise required by the user is reduced. 

[0085] The system 1 05 and its related operation are merely illustrative. In another 
embodiment, the supplier system 105 may be operated by an independent party, 
thereby facilitating communication between end-users, the supplier 102, business 
partners and others. In such an environment, the system 105 may be understood to 
operate as a broker. Further, any one or combination of the components of the supplier 
system 105 may be remotely located and operated (e.g., by an application service 
provider (ASP)). For example, any or all of the databases described above may be 
located at a remote storage facility. In another embodiment, the overall process 
implementation may be hosted by servers of the supplier 102 but executed on behalf of 
business partners of the supplier 102. In this way, a user could enter the process from 
a business partner web site and the output would flow back to the user from the 
business partner web site. Persons skilled in the art will recognize other embodiment 
within the scope of the present intention. 

[0086] Regardless of the particular arrangement, the environments described with 
reference to FIGS. 1-2 are particularly well suited as Web implementations. Providing 
the supplier historical information database, system sizing, capacity planning, solution 
plug-ins, system model selection, configuration, system ordering, and order status 
inquiry off the web allows easy user access for recommendations unique to the user 
based on the information provided. Web deployment also allows for easier and more 
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expedient process or component modifications sliould additional conditions be 
discovered in the field that could not have been covered in the testing phase of the 
product. Thus, the present embodiments allow for dynamic modification of the 
recommendations based on real usage to enhance those originally determined from 
product test phases. 

[0087] FIGS. 3-1 1 show embodiments of data flows emphasizing the nature of the 
data used and the manner in which it is generated and processed. As will be clear from 
the nomenclature, each of the data structures referred to below has a corresponding 
database shown in FIGS. 1 and 2. Illustratively, the data Is stored in tables. The tables 
may be arranged as a plurality of columns and rows, wherein each row is a record. 

[00881 Referring first to FIG. 3, an overall data flow 300 is shown. The data flow 300 
includes a collected performance data table 302, a product based summarization data 
table 304 (i.e., the agent data), and a historical data table 306 (a historical rollup of the 
product based summarization data table 304). Used in parallel, these data facilitate the 
automation and dynamic collection of solution tables 308. This can be done on a 
solution basis, a product basis or set of products basis. Other solution tables can be 
generated from asking the user a series of questions such as usage questions, 
workload descriptions, and workload consumption to generate the solution table for non- 
automated data collection. 

[0089] The system sizer 1 1 6 then consolidates these solution tables 308 and 
produces a single workload estimation table, i.e., a recommendation table 310. The 
recommendation table 31 0 outlines the recommendations based on the integration of 
the multiple solution tables 308 being consolidated into a single workload. 
Subsequently, a starting configuration data table 312 (contained in the starting 
configuration table database 121 ) is used to help select the best fit for a particular 
workload mix and a configuration and price are determined from a configuration table 
314 (contained in the configured system database 122), The result may then be 
displayed to a user for approval. After the user has seen and approved a configuration, 
the order can be placed and is represented here in the order file 31 6 (which may then 
be stored to the order table database 123). 
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[0090] FIG. 4 shows a record 402 from a performance data table 302 created by a 
performance collection function. Performance collection and monitoring is well known. 
Typically, performance collection is a function that is part of the base operating system 
of a computer system 1 06, but it may be software that is separately installed. 
Performance monitoring is a function that monitors the low level hardware and software 
instrumentation and surfaces the data in a meaningful form. It does this, for example, 
by sampling different system counters at regular time intervals. Performance monitoring' 
translates the counter values over time into values that can be used to manage the 
performance of a system. However, the particular method of collection and monitoring 
is not limiting of the present invention. 

[0091] The record 402 is an illustrative representation of this collected performance 
data and is made up of several key data entries. In the illustrated embodiment, these 
entries comprise a System Configuration entry 404, a System Resource Information 
entry 406, an Application Specific Information entry 408 and a User Specific Information 
entry 41 0. System configuration is a detailed accounting of the components of the 
system and may also include such pertinent information as the location (rack and slot) 
of the components. System resource information includes utilizations, totals, averages 
and peaks for different measurements depending on the component being measured. 
Resource information consists of resource types and their usage. Examples of resource 
information include processor utilization, memory utilization, disk arm utilization, disk 
space used. Application Specific Information describes run time consumptions for 
applications themselves. Examples of application specific information include total time 
an application took to complete, system resources used while the application was 
running, and units of work completed. User Specific Information includes the 
performance aspects as represented to the user. Examples of user specific information 
include response time information, units of work completed in a given amount of time, 
and system resources used by each unit of work. 

[0092] FIG. 5 shows a method 500 illustrating the operation of an agent function 502 

(invoked by the agent 108) with regard to the performance data table 302 and the agent 

data table 304. The agent function 502 summarizes, or otherwise processes, the 

performance data table 302 and its data content. The agent function 502 also 

automates the actual collection of the data. This process includes automating the 

gathering of the performance data, compressing the raw collected performance data 
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into summarized data which is managed and archived by the agent 108 and later 
exported by an automated means (such as a job scheduler) into the historical table 306. 

[0093] FIG. 5 also shows one embodiment of a record 504 contained in the agent 
table 304. The agent table comprises a contact information entry 506, current system 
entry 508, a job entry 510, a job type entry 512, a user entry 514, a summary entry 516 
and a time period entry 51 8. Examples of contact information include name, address, 
telephone number. The current system attributes contain elements such as CPU, 
memory and storage space sizes or capacities, configuration definitions such as 
mirrored DASD, partitions used, etc. Job information 510 is statistics relating to a 
specific job such as response time, wait time, processing time. Job type information 
51 2 is statistics on a type of job or task such as interactive, batch, or system. User data 
relates to a specific user identifier. Summary information is data summarized for a 
period of time such as a first shift or a second shift. The time period includes the 
number of samples taken by the agent function 502 and the sample period or timeframe 
(e.g., 5 or 15 minute intervals). 

[0094] FIG. 6 shows a method 600 illustrating the operation of a historical process 
602 with respect to the agent table 304 and the historical table 306. The historical 
process 602 compiles or summarizes larger amounts of alert data into monthly cells of 
information. Each computer system 106 has a history of its operation over the past, for 
example, 1 3 months (or less if monitoring has not been active for 1 3 months or more). 
After importing the agent data for the collection period, the sample is archived in the 
historical table 306 and calculations are made to calculate daily, weekly, monthly 
statistics. In addition, the job and job types are derived, and the workload and user 
supplied trends for growth, monthly and daily operations are added to the historical table 
306. 

[0095] An illustrative record 604 of the historical table 306 is shown in FIG. 6. The 
record 604 comprises an agent data entry 606, a growth rate entry 608, a shift entry 
61 0, a processor trends entry 61 2, a profile entry 61 4, a summary entry 61 6 and a time 
period entry 61 8. The agent data 606 entry may contain contact information, current 
system attributes, job information, job type, workload, and sample interval. The growth 
rate entry 608 contains calculated utilization for a particular resource. The shift is 
defined by a user and indicates when the information was collected and for which IT 
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operational shift. The trends entry 612 contains calculated projections for system 
resources (such as CPU, disk, interactive feature card) based on current growth. The 
profile entry 61 4 contains averages across different collected metrics to delineate the 
differences between what a typical day or month looks like. The summary entry 61 6 
contains the summation of calculated averages for different collected resources and 
metrics. 

[0096] As described above, the solution tables 308 may be created automatically 
{i.e., through the use of automatic performance data collection and system sizing) or 
manually. In either case, information from third party solutions providers and capacity 
planners may be used. Further, the automatic and manual methods may be used in 
tandem. Such an approach is illustrated in FIG. 7. 

[0097] FIG. 7 shows a solution input flow 700 defining how third party solutions or 
capacity planners can input their workload impact into a defined process in a more 
manual fashion while also allowing for automated solution input flows. In general, the 
solution in the flow 700 includes first asking a series of use questions 702 and secondly 
asking particular questions regarding the workload description 704 itself. In addition, 
automated solution input flow 706 are provided. Both methods (i.e., automatic and 
manual) require a defined workload consumption 708 to be assigned in order to derive 
a solution table 308. By allowing both methods as input through a common solution 
table definition the system sizer 116 can apply workload impacts from many different 
vendor sources to compile an overall system impact in an integrated fashion. 

[0098] FIG. 7 also shows one embodiment of a record 710 contained in the solution 
table 308. The record 710 is made up of several key data elements including a user 
entry 71 2, a solutions description entry 71 4, a current system attributes entry 71 6, a 
workload type entry 718, a usage period entry 720, and a workload consumption entry 
722. Examples of a user include a customer, a business partner selling the product, or 
employees of the solution provider themselves. The solutions description identifies the 
solution as a particular solution such as Lotus Notes, WebSphere, JDE OneWorld, etc. 
The current system attributes contain elements such as CPU, memory and storage 
space sizes or capacities, configuration definitions such as mirrored DASD, partitions 
used etc. The workload type is defined by the supplying vendor and examples include 
traditional, Lotus Notes, Java or other program execution models which bring differing 
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workload demands to the computer system 106. The usage period includes the number 
of data intervals and the data interval period or time frame, such as 1 months worth of 
data or 1 day or 1 week. The workload consumption is the actual use of the measured 
data on system resources like CPU, DASD and memory. 

[0099] FIG. 8 shows an embodiment of a system sizer process 800. The system 
sizer process 800 defines how the system sizer 116 processes inputs (e.g., solution 
tables) and generates the recommendation table 310. As described above, solution 
tables can be generated from third party solutions or capacity planners and adopted at 
step 802. In addition to accepting solution tables as input, the system sizer 116 may 
add product specific solution tables 308 supported within the sizer 1 1 6 Itself, as 
represented at step 804. In one embodiment, product specific solution tables supported 
by system sizer 1 1 6 include Domino Mail, HTTP Websphere, etc. At step 806, the 
system sizer 116 consolidates the workload consumption requirements from all the 
solution tables 308. The recommend table 31 0 is a result of determining, at step 808, 
the systems acceptable to support the consolidated requirements. Throughout the 
process 800 the user is provided the ability to adjust (block 81 0) the inputs, 
consolidation, and determinations made by the sizer 116. 

[00100] The recommendation table 31 0 Is a result of the system sizer process 31 0. It 
represents one or more systems with resources capable of handling the requirements. 
FIG. 8 shows one embodiment of a record 812 contained in the recommendation table 
310. Illustratively, the record 812 comprises several key data elements including a user 
entry 81 4, an estimated system attributes entry 81 6, and a time period entry 81 8. 
Examples of a user include a customer, a business partner selling the product, or 
employees of the solution provider themselves. The estimated system attributes contain 
elements such as system model, CPU, memory and storage space sizes or capacities, 
configuration definitions such as mirrored DASD, partitions used etc., and descriptive or 
cautionary comments that may apply to the specific system. The time period indicates 
whether the estimated system meets the current requirements or for a future point in 
time (e.g., 12 months) as selected by the system sizer user. 

[00101] FIG. 9 illustrates one embodiment of a comparison process 900 Implemented 
by the comparison tool 202. The comparison process 900 defines the way the 
comparison tool 202 facilitates the comparison of different product capabilities and 
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starting prices to help a user determine tine product tinat best fits their needs and budget. 
In addition to accepting recommendation tables 31 0 as input, the comparison tool 202 
may be initiated with any arbitrary list of products or criteria. By modifying the criteria 
used to display systems, the user may expand (step 902) the amount of information to 
analyze or focus on specific pieces of information. The user may choose to focus on 
the recommended criteria or expand to additional information the recommend table 310 
did not take into account. At step 904, a user may decide whether the 
recommendations match their needs. If not, the criteria may be modified at step 906. 
Once a particular product is selected, the starting configuration table 312 can be built. 
The starting configuration is a specific starting point and "ballpark" price from which to 
begin configuring a system. Some examples of product capabilities to compare include 
data used by system sizer 1 16 such as processor speed, maximum memory, maximum 
disk, etc., as well as expanded details such as maximum LAN lines, maximum 
workstations, maximum I/O processors, maximum expansion racks, etc. 

[00102] FIG. 9 shows one embodiment of a record 908 contained in the starting 
configuration table 312. The record 908 is made up of several key data elements 
including a user entry 91 0, an original system entry 91 2, a target system entry 91 4, and 
a starting price entry 916. The user is the same user as in other process steps to 
ensure continuity throughout. The original system is the detailed list of parts in the 
user's existing machine in the case of an upgrade. The target system is the system the 
user has determined best fits their needs. If original system is blank, target system 
reflects an entirely new machine. If the original system is supplied, an upgrade scenario 
is assumed. The starting price is a planning and budgeting value that sets the 
expectation for what the ultimate price will be. Both the original system and target 
system are communicated in the form of model numbers, part numbers, features, etc, 
that are used both for billing and/or manufacturing purposes. 

[00103] FIG. 1 0 shows a configuration tool process 1 000 implemented by the 

configuration tool 204. The process 1 000 defines the steps for determining a valid 

system that can be manufactured and priced. Using the starting configuration table 312 

as input, the process 1000 proceeds to step 1002 where the user modifies the product 

features. A key determinant of whether or not a feature satisfies a customer need and 

budget is the price of the feature. Therefore, at step 1004, the feature is priced and 

displayed as the user makes selections. Because any system may have complex 
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interplay between parts, a validation step must be executed anytime the user selects a 
new system feature. Thus, at step 1 006 the process 1 000 queries whether the 
configuration is valid. Examples of validation logic are prerequisite parts that must be 
on the system for a feature to function, parts that are mutually exclusive, allowed 
upgrade paths, available card and device slots, etc. If step 1 006 is answered 
negatively, the method 1000 returns to step 1002. Once a valid configuration Is 
generated, the process 1000 proceeds to step 1008 and queries the user for 
acceptance. If the user does not accept the configuration, the method 1 000 returns to 
step 1 002. By iterating through the configuration tool, the user builds the complete 
configured system desired. Once a valid configuration is accepted by the user, the 
configured system table 314 is output. The configured system table 314 includes the 
complete information necessary to bill the user and manufacture the system. 

j [00104] FIG. 1 0 shows one embodiment of a record 1 01 0 of the configured system 
table 314. The record 1 010 comprises several key data elements including a user entry 
1 01 2, a system detail entry 1 01 4, a total price entry 1 01 6 and a manufacturing input 
: entry 1 01 8. The user is the same user as in other process steps to ensure continuity 
' throughout The system detail is the detailed list of parts to build the system in the form 
^ of model numbers, part numbers, features, etc. System detail is a detailed and 
: ; complete list of features to build the system from. The total price is the price the user 
;4 can expect to be invoiced. Manufacturing input Is any additional information 
- manufacturing may need, such as special card placement, software preloads, etc. 

[00105] FIG. 1 1 shows one embodiment of an order process 1 1 00 implementing the 
order function 206. The order process 1 100 defines the necessary steps to build and 
communicate successful order acceptance. Using the configured system table 314 as 
input, the method 1 100 first determines manufacturing steps necessary to build the 
configured system at step 1 1 02. At step 1 1 04, manufacturing resources are scheduled 
and tracking numbers are assigned. At step 1 1 06, the method 1 1 00 queries whether 
the parts are available. If not, the method 1 1 00 returns to step 1 1 02. If the parts are 
available, the method 1 1 00 outputs the order table 31 6. 

[00106] One embodiment of a record 1110 contained in the order table 31 6 is shown 
in FIG. 1 1 . The order table record 1110 comprises several key data elements including 
a user entry 1 1 12, a manufacturing tracking entry 1114 and a ship data entry 1116. The 
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user entry 1112 includes, for example, the destination shipping address. The 
manufacturing tracking entry 1114 includes tracking numbers useful in tracking the 
status of the order through manufacturing. The ship data entry 1116 includes such 
things as tracking numbers that can be used for tracking shipments through common 
carriers. 

[00107] For purposes of illustration, a series of graphical user interfaces (GUIs) are 
described below. The GUIs display relevant information to users and provide fields for 
user input. In the illustrative embodiment, the GUIs are Web based and accessible 
through Web browsers executing on the customer systems 106. The GUIs may be 
stored anywhere on the supplier system 1 05 and/or may be dynamically generated in 
response to requests. It is understood that the GUIs are merely illustrative and that any 
variety of additional or modified user interfaces are contemplated as embodiment of the 
present invention. 

[00108] FIG. 1 2 shows a GU1 1 200 provided to a user accessing the uniform resource 
locator (URL) specified in the address field 1202. In this case, the URL is for a web site 
maintained by IBM. In general, the GUI provides an owner/customer a view of 
information relating to the collection of data by the agent 1 08. For example, instructions 
are provided relating to activating the agent 1 08, verify the agent 1 08 is working, and 
sending data to the supplier system 105. This information is accessible via a plurality of 
hyperlinks represented as some descriptive text, information is generally divided 
between two categories, one for existing owner/customers and one for potential 
owner/customers. Existing owner/customers have the ability to view machine data 
relating to one or more of the computer systems 1 06 after the data has been processed 
by the supplier system 1 05 by clicking a button 1 204. 

[00109] One example of processed data machine data (contained in the history tables 
database 118) which may be viewed by a user is shown in FIG. 1 3. FIG. 1 3 shows a 
GUI 1 300 containing a management summary document 1 302. The management 
summary document 1302 provides a graphical overview of the owner/customers 
computer system data after it has been processed and formatted by the supplier system 
1 05 and after it is married with other history data to project trends based on growth. 
Illustratively, three categories of projections are provided: a processor - interactive 
capacity category 1 304, a processor - system interactive category 1 306, a processor - 
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total category 1 308, and a disk space category 1 31 0. Each projection falls into one of 
three categories (acceptable, marginal, or critical) based on guidelines for the specific 
model of computer system collected. Thus, management summary document 1 302 
allows a owner/customer to determine a current usage profile and a projected profile. 

[00110] The overview provided by the management summary document 1 302 may be 
reduced to its particular details. For example, a GUM 400 shown in FIG. 1 4 displays a 
document 1402 containing bar graphs 1404 and 1406 that provide additional details for 
the management summary document 1 302. Specifically, the document 1 402 
graphically represents a specific resource (e.g., Total Processor Utilization), its history 
data, and a 3 month projection based on growth using the actual computer systems 
data. Again, the information is formatted (e.g., color-coded) to visualize acceptable, 
marginal, or critical performance and whether the guideline for that specific computer 
system is being exceeded. 

[00111] FIG. 1 5 shows a system sizer input screen 1500. The screen 1500 is 
configured to allow a user to make workload selections, which is then used by the 
system sizer 1 1 6 for initial analysis and sizing. A type of workload is specified by a user 
in a first field 1 502. A pulldown menu 1 504 is made available by clicking a button 1 504. 
The pulldown menu 1504 provides a plurality of workload types for selection by the 
user. Examples of workload types include Domino, Java, Web Commerce, Traditional, 
WebSphere, HTTP, Existing, PM400 and a generic workload. Each workload is given a 
name which is input to a name field 1 506. Illustratively, three name fields 1 506 are 
shown. Default workload names are assigned to each workload. A user can then 
assign a unique name to each selected workload. Once a workload type has been 
selected and given a name, the user may click on a button 1508 to configure another 
workload. The screen 1 500 also displays settings 1 510 for some of the options that 
affect the calculations performed in the sizing. Once a desired number of workload 
have been configured and any options have been selected, the user clicks on a "next" 
button 1510 to move to the next system sizer screen. 

[00112] FIG. 16 shows a GU1 1600 for viewing and customizing information provided 
in a solution table representing historical data. In general, the GUI 1600 is divided into 
two areas: a system information portion 1 602 and a growth information portion 1 604. 
The system information portion 1602 shows the characteristics of a system for which the 
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historical data was provided. Illustrative information includes a name of the entity 
owning the system, a serial number of the system, a system model number, an 
interactive feature of the system, a percentage of the overall CPU consumed and 
computing capacity of the processor (referenced as "System CPU"), a percentage of 
interactive computing capacity consumed and the interactive computing capacity of the 
system (referenced as "Interactive CPU"), the number of processors in the specified 
model, amount of memory (RAM) installed on the system, the utilization percentage and 
number of disk arms installed on the system, the number of the each type (i.e., 7200 
RPM, 10k RPM, etc.) of disk arm currently installed on the system (referenced as "Disk 
Arms Distribution") and amount of data storage consumed, percentage of disk storage 
consumed and total disk storage installed on the system (referenced as "Disk Storage"). 

[00113] The growth information portion 1604 includes information that will be used in 
calculating future system resource needs. System sizer projections will be based on the 
Months to Growth field 1606. Each of the resource categories 1608 has a growth trend 
field 1 610A-F associated with it. This trend shows the rate of change for the particular 
category after one month. With regard to the memory growth trend field 1 61 OF, the 
growth rate can be specified to grow like a selected category in the "Memory Matches" 
column 1612. 

[00114] FIG. 17 shows an advanced growth options GUI 1700. The GUI 1700 allows 
a user to view trends in their system performance and set future growth rates to be used 
in system sizing calculations. Graphs can then be displayed with information about 
system usage. Illustratively, a graph showing "Non-Interactive CPU" is shown. Other 
categories for which graphs may be displayed include interactive CPU, total system 
CPU, disk arms, disk storage and memory. In each case, historical system statistics are 
shown allowing exclusion of any or all months in calculating a trend. For each category, 
a current total column 1704, a current trend column 1706, a future growth column 1708 
and a future total column 1710 are shown. The current total column 1704 indicates how 
much is currently being used for a particular category. The current trend column 1706 
indicates a trend (e.g., average increase/decrease) in usage per month. The future 
growth column 1708 indicates the intended future growth rate per month. The future 
total column 1 710 indicates how much will be required at the future time. This is 
affected by the number of months specified in the Months to Growth field 1712. 
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[00115] FIG. 18 shows a system recommendation GU1 1800. The GU1 1800 contain 
system recommendation information resulting from the recommend table and which will 
be passed to the comparison tool 202. Illustratively, from the set of all computer 
systems capable of supporting the specified workload, one system is shown (indicated 
as "immediate solution"). Additionally, a system adapted to the growth trend is shown 
(indicated as "growth solution"). The system information which may be displayed to the 
user for each solution includes model/feature, processor CPW, interactive CPW, 
database capacity, N-Way, processor utilization, software pricing tier and memory. The 
model/feature information is the selected system identification. Clicking a drop-down 
menu button 1802 provides a menu of all models capable of performing the specified 
work. The processor CPW is the computing capacity of the processor and the 
interactive CPW is the computing capacity of the processor with interactive applications 
and percentage of that capacity used. The database capacity is the percentage of the 
overall CPU to used perform database processing. The N-Way is the number of 
processors in this model. Processor utilization is the percentage of overall CPU 
consumed by the workloads defined. Software pricing tear is an ID of a group 
determining pricing for software and support. The memory indicates the amount of 
memory and (RAM) required and the maximum amount the system supports. 

[00116] FIG. 19 shows illustrative comparison screen 1900. This user interface is 
configured to receive the base recommendation on system parameters and allow 
examination of the product line to determine suitable solutions that meet the specified 
requirements. The comparison data contained in the comparison screen 1900 is then 
input to the configuration tool 204. Illustratively, a list 1 902 of acceptable systems is 
shown. The systems in the list 1 902 are characterized by a plurality of system 
features/parameters columns 1904, each capable of being modified by the user. 
Because part of the illustrative recommendation is an upgrade, an existing system 
descriptor 1 906 for the system that will be upgraded is also displayed. 

[00117] The capabilities to display (the columns 1 904) can be changed by the user to 

expose additional information about the systems or hide information not important to the 

user. As an example, FIG. 20 shows a screen 2000 indicating features of the existing 

system (referenced by "830_2403_1 532") and an upgraded system (referenced by 

"830_2403_1533"). The screen 2000 displays the machine type model and 

specifications for insertion into the Configurator process. 
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[00118] FIG. 21 shows an illustrative configuration screen 2100. The configuration 
screen 2100 shows a background window 21 01 and a foreground window 2102. The 
foreground window 2102 displays current systenn options to choose from. Across the 
top of the window 21 02, tabs 21 04 can expose additional features to choose from. The 
background window 2101 provides additional tabs 2106. Activating a "proposed" tad 
21 08 displays the feature detail and price of the complete system. A slot and system 
diagram can be seen under the "Diagram" tab 21 1 0. The "Hardware" tab 21 12, 
"Software" tab 21 14, and related tabs broaden selections even further. At a lower end 
of the foreground window 2102, a "Configure" button 2120 can be clicked to force 
validation. 

[00119] The information contained in the configuration screen 21 00 is then provided 
to the order process 206. An exemplary order entry screen 2200 is shown in FIG. 22. 
The order entry screen 2200 displays a detailed list of features, a quantity for each item, 
a part number, unavailability indication, itemized pricing and a subtotal invoice amount. 
If desired, a user may remove one or more of the items and recalculate the subtotal. 

[00120] Accordingly, systems and methods are provided for increased accuracy of 
product use by automatically collecting machine data, automatically passing this data to 
servers available to customers and other users, condensing a historical view of this 
information to be fed into a workload estimator that determines the appropriate size of 
machine needed, allowing the user to modify this history to adjust for forecasted 
changes in how the product may be used in the future and allowing the user to describe 
basic changes in new workloads or additional workloads they may now choose to take 
advantage of. Once the appropriate product upgrades have been identified, the user 
has the ability to place the order for the selected upgrades or the new product 
replacement through ordering facilities, which may be web-based. This provides the 
user with the ability to track, modify, extend and order product enhancements directly 
without the need for a product expert that was previously required even for typical 
product enhancements. Through the use of product description tables, additional 
software or hardware considerations from the same or different vendors can be added 
to the product upgrade model, thereby allowing third party suppliers to affect the 
upgrade model with their products. 
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[00121] It is understood that the foregoing embodiments are merely illustrative. 
Persons sl<illed in the art will recognize additional and/or alternative embodiments which 
are within the scope of the present invention. For example, in one embodiment 
recommendations are generated automatically by the supplier system 105 without an 
explicit request from a user. For example, the supplier system 1 05 may monitor the 
computer systems using the machine information collected therefrom. When a system 
is approaching capacity limits a notification is issued to an operator of the system. The 
notification may indicate a usage trend and indicate when a system will meet or exceed 
its capacity. In response to receiving the notification, the operator may take steps to 
upgrade/enhance the system and obviate problems associated with exceeding the 
system requirements. 



Physical Device Placement 

[00122] In one embodiment, the supplier system 1 05 may also be adapted to provide 
physical device placement information. In general, physical device placement 
information includes any information specifying an appropriate location and 
configuration of a physical computer device in a computer system. The following 
embodiments are directed to physical device placement information methods and 
systems. 

[00123] FIG. 23 shows a processing system 2300 comprising a sizing system 2302 
and a configuration information supplier system 2304. The sizing system 2302 and the 
configuration information supplier system 2304 communicate with a plurality of client 
computers 2306 via a network 2308. In one embodiment, the network 2308 is the 
Internet. Illustratively, the sizing system 2312 is the supplier system 105 described 
above. Accordingly, the components of the sizing system 2302 are the same as those 
described above with reference to FIGS. 1-22. Embodiments of the configuration 
information supplier system 2304 will now be described with reference to FIGS. 24-35. 

[00124] The present embodiments provide methods and systems for handling physical 
device placement requests. In general, a physical device placement request is any 
request for information pertaining to placement of a physical device (e.g., a direct 
access storage device and a PCI card) in a computer system. 
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[00125] The following embodiments are described with particular reference to 
upgrading/enhancing computers. However, the present embodiments are applicable to 
any physical devices that benefit from periodic upgrades, enhancements or 
reconfiguration. 

[00126] FIGS. 24 and 25 show embodiments of configuration information data 
processing systems 2400 and 2500, respectively. The configuration information data 
processing systems 2400 and 2500 are also referred to herein as "system 2400" and 
"system 2500", respectively. The system 200 may be understood as a particular 
embodiment of the system 2400. Accordingly, in some cases similar terms are used in 
describing FIGS. 24 and 25 to indicate similar components. In one embodiment, the 
systems 2400, 2500 are configured as Web based systems comprising Web servers 
navigable by Web browsers. As such, the systems 2400, 2500 are particularly suited 
for Internet implementations. However, references to Web applications and the Internet 
are merely for purposes of illustration and persons skilled in the art will readily recognize 
that embodiments contemplated herein include any networked arrangement and a 
method allowing access to configuration information. 

[00127] Referring first to FIG. 24, the system 2400 generally includes a plurality of 
external client computers 241 0i, 241 02,... 241 On (collectively referred to herein as 
"external client computers 2410") and a configuration information supplier system 2404 
(also referred to herein as "supplier system 2404"). A network connection is established 
between the external client computers 2410 and the supplier system 2404 through a 
network 2412 (also referred to the "external network"). The network 2412 may be any 
local area network (LAN) or wide area network (WAN) capable of supporting the 
appropriate information exchange according to embodiments provided herein. In a 
particular embodiment, the network 241 2 is the Internet. 

[00128] Each external client computer 241 0 is shown configured with a browser 241 4 
(only one shown) to allow for navigation of network addresses, including the network 
address of the supplier system 2404. Illustratively, the browser 2414 is a Web browser. 

[00129] At a front end, the supplier system 2404 includes a security mechanism 2420. 
The security mechanism 2420 may be any combination of hardware and software 
configured to restrict access to the supplier system 2404. In one embodiment, access 
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may be restricted to register users. Accordingly, tine supplier system 2404 includes a 
registration information database 2422 which is used by the security mechanism 2420 
to authenticate users requesting access to the supplier system 2404. The registration 
information database 2422 may include usernames, user IDs, user physical addresses, 
user e-mail addresses, user passwords and the lil<e. 

[00130] The security mechanism in communication with a device placement system 
2423. In general, the device placement system 2423 comprises an interface server 
2424 and a configuration server 2430. The interface server 2424 is configured to 
format interfaces in response to a user request (e.g., from the external client computer 
2410). The interfaces 2426 are stored as a series of electronic documents in an 
interface database 2428. Illustratively, the interfaces 2426 are graphical user interfaces 
(GUI) comprising a number of fields which may be populated with Information provided 
by a configuration server 2430 or by information provided from a user, e.g., via a 
browser 241 4. 

[00131] The configuration server 2430 (also referred to herein as the "physical device 
placement server") may be any machine comprising a configuration program 2432 
which, when executed, performs a hardware device placement process according to a 
request received from an external client computer 2410. The rules for performing the 
hardware device placement process and generating a meaningful output is contained in 
a rules file 2433. The rules file 2433 contains current configuration and placement 
information (also referred to herein as rules) for a plurality of devices. The rules are 
specific to a plurality of machines, which may be identified by machine type and model. 
For each specific machine, the rules identify where a hardware device (e.g., PCI and 
DASD) Is placed and various circumstances regarding the placement. One example of 
a rules is the proper distribution of DASD devices under PCI media adapters for a 
specified level of protection. Another example is the distribution of PCI LAN adapters 
under PCI controller adapters for optimized performance. The rules file 2433 may be 
periodically updated to ensure accurate information. 

[00132] The information used by the configuration server 2430 (and specifically the 
configuration program 2432) to process a request is contained in a plurality of 
databases. In one embodiment, the databases include a customer machine information 
database 2434, a purchase order database 2436 and a base system information 
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database 2438. 

[00133] The customer machine information database 2434 contains customer 
supplied Information about specific computers. For each particular computer, such 
information may include a model number, a machine type, a plant code, hardware 
information (e.g., for the various devices resident on the computer), software 
Information and the like. Illustratively, the information contained In the customer 
machine information database 2434 may have been manually collected or automatically 
collected. Automatic machine information collection is well-known. For example, the 
AS/400 for iSeries available from International Business Machines is configured to 
sense and collect machine data in response to a predefined command (i.e., 
WRKORDINF). Embodiments for data collection which may be used to advantage are 
further described in U.S. patent application serial no. 09/892,424, filed on June 27, 
2001 , entitled APPARATUS, METHOD, AND BUSINESS METHOD FOR ENABLING 
CUSTOMER ACCESS TO COMPUTER SYSTEM PERFORMANCE DATA IN 
EXCHANGE FOR SHARING THE PERFORMANCE DATA; and U.S. patent application 
serial no. 09/892,435, filed on JUNE 27, 2001 , entitled APPARATUS, METHOD, AND 
BUSINESS METHOD FOR ENABLING CUSTOMER ACCESS TO COMPUTER 
SYSTEM EXECUTION DATA IN EXCHANGE FOR SHARING THE EXECUTION DATA, 
which are hereby incorporated by reference in their entirety. Regardless of the 
collection method, the machine data may then be transported to the supplier system 
2404 and associated with a particular user during registration. In the case of the 
AS/400, the data is transmitted from an external client computer 2410 in response to a 
user-initiated command, i.e., the WRKORDINF command. It should be noted that that 
the customer machine information may be specific to a machine different from the 
machine used to later invoke the hardware device placement process of the present 
embodiments. 

[00134] The purchase orders database 2436 provides a repository for pending 
purchase orders (also referred to herein as "Miscellaneous Equipment Specifications" 
(MES)). Each purchase order may be referenced by a purchase order number. Each 
purchase order may contain order content specifying a part{s) to be added to an existing 
machine. For example, the order content may include part names, a part number, a 
machine type, a serial number and other identifying information. 
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[00135] The base system information database 2438 contains "templates" for a variety 
of different systems. Eacli template defines the specification of a particular system. 
The templates allow a user to perform "what if" scenarios for various devices using the 
same base system information or for various base systems using the same device. 

[00136] In one embodiment, device configuration requests may also be submitted 
from an internal client computer 2440. The internal client computer 2440 executes a 
browser (e.g., a Web browser) in order to communicate with the interface server 2424. 
However, because the internal client computer 2440 resides "behind" the security 
mechanism 2420, a user of the internal client computer 2440 may not be subject to the 
same restriction requirements as a user of the external client computers 2410. 

[00137] In operation, the configuration information supplier system 2404 responds to 
requests for configuration/placement information of hardware devices. Such devices 
may include, for example, PCI cards and DASDs. The requests are submitted from 
registered users by either the external client computers 241 0 or the internal client 
computers 2440. In the former case, users are subject to an authentication process as 
implemented by the security mechanism 2420. For example, a user may be required to 
provide a user ID and password. 

[00138] Submission of requests is facilitated by providing users the interfaces 2426 
via the interface server 2424. The interfaces 2426 may include one or more request 
Interfaces comprising a number of fields. The interfaces are transmitted to the browser 
2414 and a user then inputs required information into the fields and submits the 
information to the supplier system 2404. Illustrative embodiments of a graphical user 
interface configured for submission of a configuration request are described below with 
reference to FIGS. 4-29. 

[00139] A request received by the supplier system 2404 is then forwarded to the 
configuration server 2430 for processing. In particular, the configuration program 2432 
operates to retrieve the appropriate information from the rules file 2433, while the 
configuration server 2430 retrieves information from the databases 2434, 2436 and/or 
the base system database 2438. The particular Information retrieved will depend upon 
the nature of the request. In one embodiment, requests include machine-specific 
requests, base system requests and a purchase order number request. These requests 
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will be described in more detail with reference to FIGS. 30-34 below. Regardless of the 
request type, steps are taken by the configuration server 2430 to associate the 
appropriate information from the databases 2434, 2436 and 2438 and output the 
information to the interface server 2424. The information is then transmitted to the user 
for display via the browser 2414, 2442. 

[00140] Referring now to FIG. 25, the system 2500 generally includes an external 
environment 2502 and a configuration information supplier system 2504 (also referred 
to herein as "supplier system 2504"). The external environment 2502 and a supplier 
system 2504 may be separated by an information access partition 2506. Generally, the 
information access partition 2506 may be any combination of hardware and software. 
Illustratively, the information access partition 2506 is a firewall. 

[00141] The external environment 2502 includes an external server 2508 and a 
plurality of external client computers 251 Oi, 251 02,... 251 On (collectively referred to 
herein as "external client computers 2510"). In general, the external server 2508 is 
configured to prompt a user for a user ID and password as previously specified during a 
registration time. A network connection is established between the external server 
2508 and the external client computers 2510 through the network 2512. The network 
2512 may be any local area network (LAN) or wide area network (WAN) capable of 
supporting the appropriate information exchange according to embodiments provided 
herein. In a particular embodiment, the network 2512 is the Internet. The external client 
computer 251 0 is shown configured with a browser 251 4 to allow for navigation of 
network addresses, including the network address of the external server 2508. 
Illustratively, the browser 2514 is a Web browser and the external server 2508 is a Web 
server. 

[00142] The external server 2508 communicates with an internal server 251 0 residing 
on an opposite side of the partition 2506. Illustratively, communication between the 
external server 2508 and the internal server 2510 is maintained by a Secure Gateway 
Interface (SGI) connection supported by SGI interfaces 2512a-b. A connection is 
established only after a user has been authenticated by the external server 2508. 
Following authentication, the internal server 251 0 may filter and redirect network 
address requests to prevent users from accessing unauthorized databases or network 
addresses and from determining the Internal directory structure of the configuration 
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information supplier system 2504. Tliese and otlier security features may be 
implemented by a filter program 2514. 

[00143] Configuration requests are transmitted from the internal server 251 0 to a 
technical support Web server 251 6. Illustratively, the Web server 251 6 is a Lotus 
Domino Web server. The Web server 2516 hosts a physical device placement 
assistant application 251 8 and a plurality of electronic documents 2520. The electronic 
documents 2520 contained graphical user interface placement information, diagrams, 
charts and the like. The physical device placement assistant application 2518 allows 
users to access the Web server 2516 without being prompted for additional user 
identification information (e.g., user ID and password), while restricting access to the 
electronic documents 2520 via, e.g., reader fields. As the electronic documents 2520 
are created by the physical device placement assistant application 251 8, reader fields 
within each document are tagged with the user ID of the requester. In this manner, 
access to the electronic documents 2516 is limited to the appropriate user. 

[00144] In addition to servicing requests from the external client computers 251 0, the 
Web server 251 6 also services requests from internal users, as represented by the 
internal client computer 2521 . The internal client computer 2521 may be any computer 
residing inside the firewall 2506, i.e., on the same side as the Web server 2516. 

[00145] Regardless of the original source of a configuration request, the requests are 
foHA^arded from the Web server 2516 to a physical device placement assistant hub 
2526. The Web server 2516 maintains a connection with the physical device placement 
assistant hub 2526 via a Java socket client 2522 residing on the Web server 251 6 and 
a Java socket server 2524 residing on the hub 2526. Transmission of data between the 
socket client 2522 and the socket server 2524 is in the form of a uniquely defined 
socket server interface file 2528. One embodiment of the interface file 2528 is 
described below with reference to FIGS. 26A-26B. 

[00146] Once a request is received by the physical device placement assistant hub 
2526, steps are taken to prepare a response. In particular, an input order is prepared 
by the hub 2526 and then provided to a configuration program 2530. Illustratively, the 
configuration program 2530 is NewC, available from International Business Machines, 
Inc. for iSeries and pSeries hardware. The input order is prepared to using data 
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provided from one of a plurality of sources. Illustrative sources include a base system 
information database 2529 (managed by the hub 2526), customer/machine supplied 
database 2534 (managed by a database server 2532) and a VM order minidisk 2540 
(containing purchase orders/MES orders). A request to the database server 2532 may 
be in the form of an SQL query submitted via a Java JDBC through DB2 client access 
enabler (CAE) connection. Communication between the hub 2526 and the VM order 
minidisk 2540 is made via a socket connection maintained by a socket client 2536 
residing on the hub 2526 and a socket server 2538 residing on the VM order minidisk 
2540. Once prepared, the response is sent to the requester via the interface file 2528. 

[00147] One embodiment of the interface file 2528 is described with brief reference to 
FIG. 26A-26B. FIG. 26A shows a format of the interface file 2528 when input to the 
configuration server 2430 and is referenced as interface file 2528A. FIG. 26B shows a 
format of the interface file 2528 when output from the configuration server 2430 and is 
referenced as interface file 2528B. In general, the interface file 2528A-B is defined as a 
plurality of columns and rows. Illustratively, the interface format is a physical device 
placement assistant format. The format consists a key/value pairs that represent a 
current system configuration. Accordingly, the interface file 2528A-B comprises a key 
column 2602 and a value column 2604. A description column 2606 is also provided 
and contains an intuitive description of the key/value pair. The collective entries of a 
particular row define a record of the interface file 2528. A sixth record 2608 of the 
interface file 2528 contains a first character string 2610A-B and a second character 
string 2612. The first character string 261 OA-B is representative of "new" or customer 
supplied data (i.e., data supplied in a present request) whereas the second character 
string 2612 is representative of "old" data (data previously provided by a user/machine 
and now retrieved from a data repository, e.g., the database 2534). The information 
type (i.e., old or new) is indicated by a first character, "N" and "O", in the character 
strings. In the case of the first character string 261 OA-B, the input interface file 2528A 
contains a representation of the customer supplied data (a feature code) which is 
converted into a different format in the output interface file 2528B. 

[00148] FIGS. 27-29 show illustrative embodiments of graphical user interfaces 

(GUIs) configured for facilitating a configuration request. In particular, the GUIs are 

illustrative of the electronic documents 2426 (FIG. 24) and/or the electronic documents 

2520 (FIG. 25). Referring first to FIG. 27, a GUI 2700 is shown. The GUI 2700 
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comprises a search selection window 2702. The search selection window 2702 
provides user selectable search options. Illustratively, the search options include a 
machine specific search, a base system search, and an MES search, in this case, a 
machine specific search has been selected. As a result of the selection, the GUI 2700 
provides a plant code field 2704, a serial number entry 2706, a machine field entry 2708 
and a user type field 2710. Once the appropriate information has been selected or 
entered the user may submit the request by clicking on the "Submit System Information" 
button 2712. 

[00149] FIG. 28 shows a GUI 2800 configured for a base system configuration 
request. In this case, the GUI 2800 includes a base system field 2802. A GUI 2900 
configured for an MES search Is shown in FIG. 29. In this case, the GUI 2900 Includes 
an MES number field 2902 and a "plant of origin" field 2904. 

[00150] Referring now to FIG. 30, a method 3000 Is shown illustrating steps taken to 
process a configuration/placement request. In one embodiment, the method 3000 may 
be understood as illustrating the operation of the systems 2400 and 2500. Accordingly, 
reference may be made to FIG. 24 and 25 where appropriate. For brevity and simplicity, 
reference to FIG. 24 Is emphasized. However, person skilled any art will recognize 
where the following steps are applicable to the system 2500 described with reference to 
FIG. 25. 

[00151] Method 3000 is entered at steps 3002 and proceeds to step 3004 to wait on a 
request. Once a request is received, the method 3000 proceeds to step 3006 and 
queries whether the request is from an external user. If so, steps are taken to first 
authenticate the user. Accordingly, the method 3000 proceeds to step 3008 where 
authentication takes place. At steps 301 0, the method 3000 queries whether the 
authentication was successful. If not, the request is rejected at steps 3012 in the 
method 3000 returns to step 704 to wait on another event. If, however, the 
authentication is successful the method 3000 proceeds to step 301 4 where the request 
may be rerouted and filtered. The request is then processed according to the particular 
request type at step 301 6. Depending on the request type, one or more of the 
databases 2434,1246 and 2438 are accessed. At step 3018, a response is submitted to 
the requester. The method 3000 then returns to step 3004 to wait on another event. 
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[00152] FIG. 31 shows a method 31 00 for processing various request types at step 
3016. Method 3100 is entered at step 3102 and proceeds to step 3104 to query 
whether the request is a machine specific request. That is, a determination is made as 
to whether a user has submitted a machine type, a plant code and a serial number. If 
so, the customer/machine supplied database 2434 is accessed at step 3106. At step 
31 08, the method 31 00 queries whether data was found for the particular machine. If 
the user has not previously provided the data been no data is located at step 31 08 and 
an error message provided to the user at step 31 1 0. If the appropriate data is located at 
step 31 08, the method 31 00 proceeds to step 31 1 2 where a response is prepared. One 
embodiment of step 311 2 is described below with reference to FIG. 32. 

[00153] Returning to step 31 04, if the request is not for a specific machine the method 
3100 proceeds to step 31 14 and queries whether the request is a base system request. 
If so, the method 31 00 proceeds to step 31 1 6 to access the base system database 
2438 in an attempt to locate the appropriate data. At step 31 1 8, the method queries 
whether the data was located. If not, an error message is provided to the user at step 
31 1 0. Otherwise, the method 31 00 proceeds to step 31 20 where a response is 
prepared. One embodiment of step 3120 is described below with reference to FIG. 33. 

[00154] Returning again to step 31 1 4, if the request is not a base system request the 
method 3100 proceeds to step 3122 and queries whether the request Is an MES order 
number request. If so, the purchase orders database 2436 is accessed at step 3124 in 
an attempt to locate the appropriate data. At step 3126, the method 31 00 queries 
whether the data was located. If not, the requester is provided with an error message at 
step 31 10. Otherwise, the method 3100 proceeds to step 3128 to prepare a response. 
One embodiment of step 3128 is described below with reference to FIG. 34. 

[00155] If steps 31 04, 31 1 4 and 31 22 were each entered negatively, the method 31 00 
proceeds to step 31 30 to handle other request types according to predefined rules. 
Examples of requests which may be handled at step 3130 include requests to view help 
information, display error messages, jump to other Web pages view hyperlinks, etc. 
The method 3100 then exits at step 31 32. 

[00156] FIG. 32 shows one embodiment of the processing occurring at step 31 12. 
The method 3200 is entered at step 3202 and proceeds to step 3204 to prepare any 
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existing data which may be associated with the data request. Such data includes any 
information retrieved from the customer/machine reported database 2434. At step 
3205, the user is given the opportunity to edit the existing data. At step 3206, the user 
may select additional feature content. At step 3207, the existing data (including any 
edits an/or additional features) is combined with the new data submitted by the user in 
the current request. This combination of data is handled by the configuration program 
2432 which makes use of configuration placement rules contained in the rules file 2433. 
The configured data output is prepared at step 3208 and a response is built at step 
321 0. The user may then choose to iterate the foregoing steps or exit at step 3212. 

[001571 FIG. 33 shows a method 3300 illustrating the processing occurring at step 
3120 (i.e., handling of a base system request). Base system requests handled by 
method 31 00 allow a user to perform "what if" scenarios. As such method 3300 may be 
iterated for various devices using the same base system information or for various base 
systems using the same device. The method 3300 is entered at step 3302 and 
proceeds to step 3304 where the base system data is prepared. At step 3305, the user 
is given the opportunity to edit the existing data. At step 3306, the user may select 
additional feature content. At step 3307, the existing data (including any edits an/or 
additional features). Using the configuration placement rules the base system data is 
Incorporated with the data supplied by the current request at step 3306. The configured 
data output is prepared at step 3308 and a response is built at step 331 0. The method 
3300 then exits at step 3312. 

[00158] FIG. 34 shows a method 3400 illustrating the processing occurring at step 
828 (i.e., handling of an MES order number request). The method 3400 is entered at 
step 3402 and proceeds to step 3404 to retrieve the machine type and serial number 
from the purchase order database 2436 according to the user specified MES order 
number. At step 3406, feature content is preloaded and a request is prepared using the 
retrieved machine type and serial number. In particular, data may be retrieved from the 
customer supplied database 2434. In this manner, a machine specific request is 
created without requiring the user to input the machine type and serial number. 
Accordingly, the request prepared at step 3406 may be handled according to method 
900 described above with reference to FIG. 32. 
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[00159] For each configuration request type, a response containing configuration and 
placement information is returned to the user. FIG. 35 shows one embodiment of a GUI 
3500 configured with placement information in response to an MES type request. In 
particular, the GUI 3500 indicates the placement of a new 2749 lOA PCI card (obtained 
from the MES order content) within the second 5074 frame (obtained from the 
customer/machine supplied data) on the system specified by the particular machine 
type, model and serial number. 



Automation of Software Upgrades 

[00160] In one embodiment, the supplier system 1 05 may also be adapted to 
coordinate software upgrades for the software programs installed on servers/computers 
in the customer system 102. The following embodiments are directed to software 
upgrade methods and systems. 

[00161] In the software upgrade process described below, a combination of a 
customer machine's vital product data (VPD) and a set of supplier (e.g., IBM) records 
are analyzed to determine whether or not the customer/user is a candidate for 
performing the particular software upgrade task. If for any reason, the user's system is 
too complex or the records indicate that required contracts do not exist, the user will not 
be allowed to proceed but will be directed to telesales for assistance. If the user is 
eligible for the particular upgrade offering, the user will be asked appropriate questions, 
and an order will be built based on the answers. 

[00162] FIG. 36 shows one embodiment of a processing system 3600 for providing 
software upgrades to customers. The processing system 3600 generally comprises a 
customer system 3602 and a supplier system 3605. Illustratively, customer system 
3602 and supplier system 3605 may be adapted from and comprise similar components 
as customer system 102 and supplier system 105, respectively. A network connection 
is established between the customer system 3602 and the supplier system 3605 
through a network 3612 (also referred to as the "external network"). The network 3612 
may be any local area network (LAN) or wide area network (WAN) capable of 
supporting the appropriate information exchange according to embodiments provided 
herein. In a particular embodiment, the network 3612 is the Internet. 
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[00163] In one embodiment, the processing system 3600 is configured as a Web- 
based system comprising Web servers navigable by Web browsers. As such, the 
processing system 3600 is particularly suited for Internet implementations. However, 
references to Web applications and the Internet are merely for purposes of illustration 
and persons skilled in the art will readily recognize that embodiments contemplated 
herein include any networked arrangements for processing software upgrade requests. 

[00164] In one embodiment, the customer system 3602 comprises a plurality of 
customer computers 361 0i, 36102,... 361 On (generally referred to herein as "customer 
computers 3610") connected to the supplier system 3605. Although the customer 
computers 3610 are shown in Figure 36 as individually connected through the network 
3612, it is contemplated that a plurality of customer computers 3610 may be networked 
and that one of the networked customer computers 3610 may comprise a server 
computer which is connected through the network 3612 to the supplier system 3605. In 
one embodiment, each customer computer 3610 is configured with a browser 3614 
(only one shown) to allow for navigation of network addresses, including the network 
address of the supplier system 3605. Illustratively, the browser 361 4 is a Web browser. 

[00165] Each customer computer 361 0 includes an installed software database 361 6 
containing information (e.g. software identification and version/release level) about the 
software that is installed on the customer computer. One commercially available 
implementation of this software database is the iSeries Vital Product Data (VPD) from 
International Business Machines, Inc. Each customer computer 3610 further comprises 
a data collector agent 3617 configured to automate collection, summarization and 
transmission of the software inventory data. The data collector agent 361 7 may include 
a combination of software and hardware. One commercially available example of a 
data collector agent is the Electronic Service Agent™ for AS/400 from International 
Business Machines, Inc. The software inventory data collected by the data collector 
agent 3617 may be transmitted to the supplier system 3605 and stored in a 
consolidated inventory database 3650. 

[00166] At a front end in connection to the network 361 2, the supplier system 3605 
includes a security mechanism 3620 which may include a firewall mechanism to protect 
the supplier system 3605. The security mechanism 3620 may be any combination of 
hardware and software configured to restrict access to the supplier system 3605. In one 
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embodiment, access may be restricted to registered users. Accordingly, the supplier 
system 3605 includes a registration information database 3622 thiat is used by the 
security mechanism 3620 to authenticate users requesting access to the supplier 
system 3605. The registration information database 3622 may include usernames, user 
IDs, user physical addresses, user e-mail addresses, user passwords and the like. The 
registration information database 3622 may also contain the relationship between the 
user ID and the appropriate installed software inventory in the consolidated inventory 
database 3650 to ensure the privacy of individual customer information. 

[00167] The security mechanism is connected to a software upgrade process system 
3623. In general, the software upgrade process system 3623 comprises an interface 
server 3624 and a software upgrade process server 3630. The interface server 3624 is 
configured to format interfaces in response to a user request (e.g., from the external 
client computer 361 0). The interfaces 3626 are stored as a series of electronic 
documents in an interface database 3628. lilustratively, the interfaces 3626 are 
graphical user interfaces (GUI) comprising a number of fields which may be populated 
with information provided by a software upgrade process server 3630 or by information 
provided from a user, e.g., via a browser 3614. 

[00168] The software upgrade process server 3630 may be any machine comprising a 
software upgrade process program 3632 which, when executed, performs a software 
upgrade process according to a request received from an external client computer 
3610. The information utilized by the software upgrade process server 3630 (and 
specifically the software upgrade process program 3632) to process a request Is 
contained in a plurality of databases 3636. In one embodiment, the databases 3636 
include a consolidated inventory database 3650, a subscription entitlement database 
3652, a keyed management system (KIVIS) database 3654, and a product topology 
database 3656. 

[00169] In operation, the software upgrade process system 3623 responds to 
requests for software upgrades submitted from registered users by the external client 
computers 361 0, or alternatively, by the internal client computers 3640. In the former 
case, users are subject to an authentication process as implemented by the security 
mechanism 3620. For example, a user may be required to provide a user ID and 
password. The internal client computers 3640 may be accessed by a supplier system 
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user, such as a sales representative, for example. The internal client computer 3640 
executes a browser 3642 (e.g., a Web browser) In order to communicate with the 
interface server 3624. However, because the internal client computer 3640 resides 
"behind" the security mechanism 3620, a user of the internal client computer 3640 may 
not be subject to the same restriction requirements as a user of the external client 
computers 361 0. 

[00170] Submission of a request is facilitated by providing a user one or more 
interfaces 3626 via the interface server 3624. The interfaces 3626 may include one or 
more request interfaces comprising a number of fields requesting information. The 
interfaces are transmitted to the browser 3614 and a user then inputs required 
information into the fields and submits the information to the supplier system 3605. 
Illustrative embodiments of a graphical user interface configured for submission of a 
software upgrade request are described below with reference to FIGS. 38-46. 

[00171] A request received by the supplier system 3605 is fonwarded to the software 
upgrade process server 3630 for processing. In particular, the software upgrade 
process program 3632 operates to retrieve the appropriate information from the 
databases 3636. The software upgrade request will be described in more detail with 
reference to FIGS. 37-51 below. Generally, in response to a software upgrade request, 
steps are taken by the software upgrade process server 3630 to associate the 
appropriate information from the databases 3636 and output the information to the 
Interface server 3624. The information is then transmitted to the user for display via the 
browser 3614, 3642. 

[00172] FIG. 37 is a flow diagram illustrating one embodiment of a method 3700 for 
processing a software upgrade request. In one embodiment, the method 3700 may be 
understood as illustrating the software upgrade program 3632 as related to the 
operations of the supplier system 3605 and the customer system 3602. FIGS. 38-46 
show illustrative embodiments of graphical user interfaces (GUIs) configured for 
facilitating a software upgrade request. In particular, the GUIs are illustrative of the 
electronic documents 3626 in the interface database 3628 (FIG. 36). Method 3700 is 
discussed below with references to FIGS. 36-46. 
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[00173] Method 3700 is entered at step 3702 and proceeds to step 3704 to wait on a 
login request. In one embodiment, a customer may login to the supplier system 3605 
utilizing a registered login name and password. Figure 38 illustrates one embodiment of 
a GUI 3800 configured for a login request. A user may enter a login name in a User ID 
field 3810 and a password in a password field 3820. GUI 3800 may also Include links 
3830 to information a customer may find useful and registration links 3840 for new 
customers. Once a login request is received, the method 3700 proceeds to step 3705 
to authenticate the login name and password. If the login request is rejected at step 
3705, the method 3700 returns to step 3704 to wait on another login request. If the 
login name and password authentication is successful, the method 3700 proceeds to 
step 3706 to display messages for the user. The messages may include software 
upgrade notifications, order status notifications, and other messages for the user. 
Figure 39 illustrates one embodiment of a GUI 3900 configured for displaying messages 
to a user. In one embodiment, the user may click on a message to view details of the 
message. As shown In Figure 39, a software upgrade notification 3910 and two order 
status notifications 3920 are displayed. A user may view the software upgrade 
notification 3910 by selecting or clicking on the software upgrade notification 3910 in 
GUI 3900. In one embodiment, messages to the user may also be electronically 
delivered to an e-mail address of the user. Alternatively, an e-mail may be sent to the 
user to Indicate that one or more messages are available. 

[00174] Referring back to Figure 37, after displaying the available messages to the 
user, the method 3700 waits at step 3707 for the user to select a process request. In 
step 3708, method 3700 determines whether the user's request is a software upgrade 
request. If the process request Is not a request for a software upgrade, then method 
3700 proceeds to process other user requests at step 371 0 and exits at step 3790. If 
the process request is a request for a software upgrade, the method 3700 displays more 
detailed information regarding the available software upgrade and prompts the user to 
select a specific customer system to be upgraded at step 3714. 

[00175] Figure 40 illustrates one embodiment of a GUI 4000 configured for user 

selection of a specific customer system to be upgraded. In one embodiment, GUI 4000 

displays more detailed information 4010 of the software upgrade notification which may 

also include instructions for sending a software upgrade request for a specified system. 

As shown in Figure 40, the GUI 4000 also includes a system selection field 4020 which 
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lists the customer systems which may be upgraded with the software upgrade. The list 
of customer systems provided in the system selection field 4020 may be retrieved or 
compiled from a customer/user database containing information provided by the 
customer/user during the user/product registration process. In one embodiment, the 
user may select the system to be upgraded with the software upgrade and click on a 
selection button (i.e., "GO" button) 4030 provided in GUI 4000 to indicate a software 
upgrade request from the user. 

[00176] After receiving the software upgrade request for the selected system from the 
user, the method 3700 displays a selection target releases (i.e., version/release of the 
software upgrade)Jn step 3716. Figure 41 illustrates one embodiment of a GUI 4100 
configured for user selection of a target release for the software upgrade. The GUI 
41 00 may include a display 411 0 of information regarding the target release and/or 
instructions for selecting the target release for the software upgrade. The GUI 41 00 
also includes a target release selection field 4120 listing all available target release for 
the software upgrade based on the customer's current release of software. The 
customer's current release of software and the list of available target release provided in 
the target release selection field 4120 may be determined from data in a customer/user 
database (e.g., registration information database 3622 in Figure 36) containing 
information provided by the customer/user during the user/product registration process 
and the product topology database 3656. The customer's current release of software 
may also be displayed in a current release field 41 30 in GUI 4100. In one embodiment, 
the user may select the target release for the software upgrade and click on a selection 
button (i.e., "GO" button) 4140 provided in GUI 4100 to indicate the desired target 
release for the software upgrade. 

[00177] After receiving the selection for the desired target release for the software 

upgrade, the method 3700 displays a selection of languages for the software upgrade at 

step 371 8. Figure 42 illustrates one embodiment of a GUI 4200 configured for user 

selection of languages for the software upgrade. The GUI 4200 may include a display 

4210 of information regarding the available languages and/or instructions for selecting 

the languages for the software upgrade. As shown, the GUI 4200 includes a primary 

selection field 4220 and a secondary language selection field 4230. In one 

embodiment, the user/customer may select a primary language and one or more 

secondary languages supported in the customer system's environment. The 
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user/customer may click on a selection button (i.e., "GO" button) 4240 provided in GUI 
4200 to indicate the desired languages for the software upgrade. 

[00178] The information provided by the user/customer in steps 371 4, 371 6, and 371 8 
are illustrative of one embodiment of the invention. It is contemplated that default 
selections may be selected for the user based on information contained in the 
customer/user database and that other additional information may be provided by the 
user/customer and utilized to process the software upgrade request. In another 
embodiment, the language preference can be derived from information associated with 
the customer's machine stored in supplier system databases such as the registration 
database 3622 and the consolidated inventory database 3650. After receiving the 
language selections from the user, the method 3700 proceeds to validate and formulate 
the software upgrade order at step 3720. Details for step 3720 are provided with 
reference to method 4700 in Figure 47. 

[00179] Figure 47 is a flow diagram illustrating one embodiment of a method 4700 for 
validating and formulating a software order. Method 4700 begins at step 4702 and 
proceeds to step 471 0 to collect software inventory data from the selected customer 
system to be upgraded with the software upgrade. In one embodiment, the steps for 
collecting software inventory data are performed interactively during the software 
upgrade process between the supplier system 3605 and the customer system 3602 to 
get the most recent information. In another embodiment, the steps for collecting 
software inventory data may be performed in batch mode. In one embodiment, machine 
software inventory is sent directly from the selected hardware of the customer system as 
directed by the customer. An example of the software inventory data is the iSeries vital 
product data (VPD) 4712 from International Business Machines, Inc. For customer 
systems which utilize logical partitioning (i.e., LPAR), software inventory may be 
collected separately for each logical partition, and the software upgrade may be 
performed individually for each logical partition. 

[00180] In another embodiment, the machine's software inventory is obtained through 
the consolidated inventory database 3650 that is collected asynchronous to the 
invocation of the software upgrade request. In such case, each registered machine may 
provide its installed software inventory periodically (e.g., nightly, weekly 3650, or when a 
change in software Inventory is detected) by calling in to the supplier system, and the 
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machine's installed software inventory is stored in the consolidated inventory database 
3650 and indexed by a machine identification number, such as a serial number. Figure 
48 illustrates one embodiment of a consolidated inventory data table 4800 contained in 
a consolidated inventory database 3650. Each record in the consolidated inventory 
data table 4800 comprises a machine identification entry 4802, a product code entry 
4804 for each software product, a product name entry 4806, a 

version/release/modification (VRM) number entry 4808 (e.g., V4R5M0), and an installed 
language entry 481 0. Optional features of a product in a suite of products may be 
reported separately and individually with individual product codes. Embodiments for 
data collection which may be used to advantage are further described in U.S. patent 
application serial no. 09/892,424, filed on June 27, 2001 , entitled APPARATUS, 
METHOD, AND BUSINESS METHOD FOR ENABLING CUSTOMER ACCESS TO 
COMPUTER SYSTEM PERFORMANCE DATA IN EXCHANGE FOR SHARING THE 
PERFORMANCE DATA; and U.S. patent application serial no. 09/892,435, filed on 
JUNE 27, 2001 , entitled APPARATUS, METHOD, AND BUSINESS METHOD FOR 
ENABLING CUSTOMER ACCESS TO COMPUTER SYSTEM EXECUTION DATA IN 
EXCHANGE FOR SHARING THE EXECUTION DATA, which are hereby incorporated 
by reference in their entirety. 

[00181] Referring back to Figure 47, after collecting the software inventory, the 
method 4700 validates business contracts (e.g., software subscription) at step 4720 to 
ensure that the machine whose software is being upgraded has the business 
authorization to upgrade the software. In one embodiment, a software subscription is 
validated through checking the subscription entitlement database 3652 to verify the 
machine identification number and the corresponding subscription number. A valid 
software subscription typically indicates that the selected hardware for the customer 
system is entitled to receive the software upgrade. 

[00182] Method 4700 then checks asset and entitlement in step 4730. In one 

embodiment, entitlement check Is performed via activation keys checks for entitlement 

of keyed software products. Software products with activation keys may be verified 

against a keyed management system (KMS) database 3654. In this embodiment, 

method 4700 sends a query into the KMS database 3654, and the KMS database 

returns a list of permanent keyed software products for the specified hardware serial 

number system which are then cross-checked with the software products obtained in 

45 



step 4710. 



[00183] Then, at step 4740, method 4700 determines the software to be ordered. In 
one embodiment, the software to be ordered is determined by filtering and transforming 
the software inventory data. Related products that need to be upgraded along with the 
target release of the software upgrade may also be determined in this step. For 
example, when a base operating system is upgraded, other pre-requisite and co- 
requisite software may need to be upgraded as well. Details for step 4740 are provided 
with reference to method 5000 in Figure 50. 

[00184] Figure 50 is a flow diagram illustrating one embodiment of a method 5000 for 
determining software to be ordered. The Product Topology database 3656 is utilized 
throughout method 5000 and contains product information that describes the software 
product configuration software product entitlement (e.g. charge or no charge product), 
product introduction date, product withdrawal date, and business contractual 
associations. In one embodiment, the product topology database 3656 includes data 
tables for one or more of the following categories: all known products, supported 
products, subscription products, subscription identifiers per product, entitled products, 
free products, withdrawn products, cross reference Ids, cross release expansions, cross 
release collapses, products with multiple valid versions, valid target releases, order 
nomenclature, valid product releases, valid languages, licensing changes, and products 
to ignore. 

[00185] Method 5000 begins at step 5002 and proceeds to filter the software 
inventory at step 5010. In the Data Scrub step 5010, the customer's installed software 
inventory is examined to remove products that cannot be processed for upgrade. These 
unprocessable products may include known products to ignore (e.g. internal and non- 
orderable products), products that are not contained in the product topology {i.e. third 
party products), and potentially redundant or known erroneous product records. 

[00186] After the software inventory has been filtered, method 5000 proceeds to 
categorize the remaining software inventory in step 5020. In the Categorize Existing 
Products step 5020, the remaining software inventory (result from step 5010) is 
examined to identify the actual products that will be upgraded and to meaningfully 
categorize the other products. The products may be categorized into categories such 
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as, products not supported by the software upgrade program and entitled products for 
which the customer does not have keys (e.g., as determined in step 4730). 

[00187] Figure 51 shows one embodiment of product categories utilized for step 5020. 
In one embodiment, the product categories include unsupported products 51 12, free or 
no charge products 51 14, non-subscription products 51 16, supported subscription 
products 511 8, failed entitlement products 5120, withdrawn products 5122, and ignored 
products 5124. In one embodiment, the overall categorization of the remaining software 
products 51 10 may be stored and displayed to the user. The Supported Subscription 
Products 51 1 8 includes a list of valid keyed subscription products and non-keyed 
subscription products with valid subscriptions that will be input into step 5030 for 
continued upgrade processing. 

[00188] Referring back to Figure 50, the categorized software products from step 
5020 are mapped to the desired target releases in a Release to Release Mapping step 
5030. In one embodiment, each software product in each release is assigned a Cross 
Release Identifier (GRID), and the GRID for the base release is matched to the GRID for 

- the target release to determine which products will be ordered. Figure 49 illustrates one 
embodiment of a Cross Release Identifier (GRID) Map 4900. The GRID map 4900 may 

: be included as part of the product topology database 3656. In one embodiment, each 
record in the GRID map 4900 comprises a Cross Release ID description entry 4902, an 
index entry 4904, a release entry 4906, a product ID entry 4908, an option number entry 
4910, a version entry 4912, and a title/description entry 4914. In other embodiments, 
each record in the GRID map may include other entries such as, a subscription entry, a 
key entry, an ordering ID entry, a base product entry, and other entries describing a 
software product. The Product Topology database 3656 may also include GRID 
Expansion tables and GRID Collapse tables for products which need additional 
mapping. Through GRID Expansion tables, the Release to Release Mapping step takes 
into account situations where a single product in the base release expands to multiple 
products in the target release. Through GRID Collapse tables, the Release to Release 
Map also ensures that the most recent version of a target product is ordered in 
situations where a product in the target release may have more than one released 
versions (i.e. a Beta version and a Formal version). 
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[00189] Figure 52 illustrates embodiments of the Release to Release Mapping step 
5030. As shown in Figure 52A, a base release 5202 (e.g., currently installed software) 
is mapped directed to the target release 5204. For example, referring to GRID map 
4900, a base release MQSERIES release V4R1 (version V3R7M0) may be directly 
mapped to a target release MQSERIES V4R5P (version V5R2M0). Figure 52B 
illustrates a GRID collapse mapping where two base releases 5212, 5214 are combined 
into one target release 5216. For example, referring to GRID map 4900, base releases 
MQSERIES release V4R3 (version V4R2M0 and V4R2M1) may be mapped to one 
target release MQSERIES V4R5P (version V5R2M0). Figure 52G illustrates a GRID 
expansion mapping where one base release 5222 is expanded into two target releases 
5224, 5226. For example, referring to GRID map 4900, base release MQSERIES 
release V4R1 (version V3R7M0) may be mapped to two target releases MQSERIES 
V4R5 (version V4R2M1 and version V5R1 MO). Figure 52D illustrates a GRID mapping 
step where the base release 5232 cannot be mapped to a target release which may 
occur, for example, when a product has been withdrawn. 

[00190] Since software products may change their characteristics from one 
version/release to another version/release, the proposed software products from the 
Release to Release Mapping step 5030 is re-categorized in step 5040 to ensure that the 
resultant order continues to be coherent (e.g. does not contain unsupported or 
withdrawn products). The Gategorize Proposed Products step 5040 may include, but 
may not be limited to, any category movement of products after the Release to Release 
Map, additions of no-charge products that became available in the target release, re- 
categorization of products that have been withdrawn, re-categorization of any target 
products the tool does not support, and identification of any products that have 
experienced licensing and/or term and conditions changes from the old release to the 
new release. The categorization in Gategorize Proposed Products step 5040 may be 
performed similarly to the Gategorize Existing Products step 5020. 

[00191] After re-categorizing the proposed order, a list of products to be ordered is 

generated in Generate Order Records step 5050. To produce complete and accurate 

product order records, step 5050 takes into account situations where the fulfillment 

systems use distinctly different identifiers for products than the system VPD. The 

Product Topology database 3656 contains tables that translate VPD Product ID (PIDs) 

into Order PIDs. This transform also ensures proper grouping of products are created 
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for situations where multiple products will be placed on the same distribution media (i.e. 
CD or Tape Cartridge) to reduce distribution cost and minimize handling for the 
customer. In addition, the correct languages for each product are inserted in the order 
to match the existing system prior to the upgrade. Method 5000 exits at step 5090 and 
returns to method 4700, which ends at step 4090 and returns to method 3700. 

[00192] Referring back to Figure 37, after the software upgrade request has been 
processed in step 3720, the method 3700 displays an upgrade order list containing a list 
of software products to be ordered/upgraded at step 3722. Figure 43 Illustrates one 
embodiment of a GUI 4300 configured for user acceptance of a software upgrade order. 
The GUI 4300 may include a software upgrade order 4310 and information/Instructions 
4320 for a user response to the software upgrade order. In one embodiment, the 
software upgrade order 431 0 may list subcategories of products, including, for example, 
products currently covered under software subscription 4330 and other covered 
products 4340. GUI 4300 may separately list categories of products that will not be 
Included in the upgrade order, including, for example, products withdrawn from 
marketing 4350 and products currently not supported for upgrade through this process 
4360. Each product listed may include a product ID 4370, a version/release (VRM) 
number 4372, a product description 4374, and an option number 4375. The user may 
accept the upgrade order by clicking an "ACCEPT" button 4380 or decline the upgrade 
order by clicking a "CANCEL" button 4390. Optionally, the generated upgrade order 
may be saved and/or printed for the customer's reference. 

[00193] The method 3700 then determines whether the user/customer has accepted 

the upgrade order at step 3724. If the user/customer declines the upgrade order, then 

method 3700 exits at 3790. If the user/customer accepts the upgrade order at step 

3724, then method 3700 proceeds to process the upgrade order. At step 3726, method 

3700 requests the user/customer to verify the required proof of entitlement for the 

products in the software upgrade order. Figure 44 illustrates one embodiment of a GUI 

4400 configured for user confirmation of entitlement to a software upgrade. The GUI 

4400 may include information/instructions 4410 for the user/customer, a list 4420 of 

products that require proof of entitlement, an acceptance buttons 4430 and a decline 

button 4440. If the user/customer declines or is unable to verify that the required 

document can be produced, then method 3700 may exit at step 3790. In another 

embodiment, electronic proof of entitlement may be utilized to automate the entitlement 
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verification. 

[00194] Then, at step 3728, method 3700 verifies the customer shipping address for 
the upgrade order, and provides final approval of the upgrade order. Figure 45 
illustrates one embodiment of a GUI 4500 configured for user verification of shipping 
address for a software upgrade order. The GUI 4500 may have a variety of fields 441 0 
with default entries compiled from customer/product registration information (3622). 
The user/customer may update the shipping information if necessary. The GUI 4500 
also provides an acceptance button 4520 for proceeding to finalize the software 
upgrade order. 

[00195] After customer approval, the upgrade order may be processed through an 
order logic resulting in a purchase order list of products for the product distribution 
center. Then, the purchase order is submitted to the software manufacturing center 
(e.g., product fulfillment and distribution center) at step 3730, and the ordered products 
may be assembled and shipped by the software manufacturing center to the customer. 
Alternatively, ordered products may be electronically downloaded or transferred to the 
customer's system. 

[00196] At step 3732, the method 3700 provides a receipt for the upgrade order, 
which may include a confirmation or tracking number for the upgrade order. Figure 46 
illustrates one embodiment of a GUI 4600 configured for providing a receipt with 
confirmation/tracking number for a software upgrade order. The GUI 4600 may include 
a confirmation/tracking number 4610 and a software upgrade order receipt 4620. The 
user/customer may utilize the confirmation/tracking number to check the order status. 
Optionally, the method 3700 may send order status notifications (e.g., by e-mail or other 
electronic messaging systems) to the user/customer at each order status change (e.g., 
when order is shipped) at step 3734, and the method ends at step 3790. 

[00197] While the foregoing is directed to embodiments of the present invention, other 
and further embodiments of the invention may be devised without departing from the 
basic scope thereof, and the scope thereof is determined by the claims that follow. 
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